一句話破題

Laravel 已經一路推進到 13 版，framework 骨架大改、Starter Kit 換代、甚至內建了 AI SDK。如果你手上還是幾年前那套心智模型，有些東西已經不只是「語法變了」，而是整張地圖都要重畫——這 30 天就是帶你把它重畫一次。

這個系列是什麼

《我推的Laravel》第二季。第一季是 2023 年的鐵人賽內容，賽後擴充整理成上下兩冊出版，定位是「資深同事帶你上手」：不翻譯官方文件，只講開發中真正會用到、會踩雷的地方。S2 延續同樣的定位，但基準線整個拉到 Laravel 13。

這一季會做兩件事：

1. 所有語法、寫法、目錄結構都對照過 Laravel 13 官方文件。這幾年變動不小：Laravel 11 對應用程式骨架做了近十年來最大幅的簡化（Kernel.php 整個消失）、Laravel 12 把 Starter Kit 全部換代、Laravel 13 走向 AI 原生。這些如果照舊教材自學，很容易學到一套「能動，但不是現在建議的寫法」。
2. 新功能就近安插進相關主題，不是全堆在最後幾天當附錄。路由那天就會講到新的流量限制寫法、Eloquent 進階那天就講新的屬性轉型寫法，而不是前面 25 天舊內容、最後 5 天才丟一堆新名詞給你。

另外先講清楚：這一季的更新我是全程搭配 AI 協作完成的，之後文章裡不會每篇重複提醒。分工是——架構、觀點取捨、範例設計由我主導；「逐條去對照官方升級指南跟釋出說明」這種需要大量查找比對、還要正確引用來源的工作交給 AI，效率跟涵蓋率都比我自己翻文件好，你會看到不少「這是哪個版本開始變的」明確標註，就是這個協作方式的產物。判斷取捨最後都是我拍板，過程記錄在系列附帶的 DECISIONS.md。

為什麼要用「重畫地圖」而不是「補課」來形容這件事

我一開始想把這系列定位成「Laravel 10→13 補課包」，後來放棄了這個說法，原因是「補課」暗示著你只需要在既有知識上疊加幾個新知識點，但實際狀況更接近：你腦中那張「一個 Laravel 請求怎麼被處理」的地圖，有一部分的座標系統整個換了。舉個具體例子：如果你熟悉 Laravel 10，看到中介層的問題，你的直覺反應會是「去 Kernel.php 查」；但 Laravel 11 之後 Kernel.php 根本不存在，你的直覺反應本身就會把你導向錯誤的方向，浪費的時間往往比單純不知道答案還多——因為你要先發現「我的直覺是錯的」，才能開始找正確答案。

這也是為什麼這系列選擇用「重新蓋一個 blog-app 專案」而不是「條列版本差異表」的方式呈現。差異表適合已經很熟 Laravel、只想快速抓重點更新的人；但如果你的目標是重建一套能長期依賴的直覺，跟著一個真實專案從零走一遍，讓新寫法變成你「這樣寫很自然」的預設反應，會比背一張表更持久。

這系列適合誰

• 有基礎 Laravel 開發經驗、想把知識更新到 13 版的中階工程師——你可能已經做過幾個專案，但這幾年沒特別追新版動態，這系列會幫你快速抓出「哪些是我以前的寫法已經不是主流了」。
• 完全沒碰過 Laravel、但已經有基礎 PHP/物件導向概念的讀者——從 Day 1 到 Day 30 照順序讀完，就能建立一套「現在就是正確答案」的知識，不用先學一套舊的再學怎麼轉換。
• 正在維護舊版專案、考慮要不要升級的工程師——每次遇到版本差異都會註明「哪個版本開始變的」「舊寫法還能不能用」，可以當作升級評估的參考地圖。

這三種讀者的閱讀策略其實不太一樣，這裡順便說清楚，省得你走冤枉路：

• 如果你是第一種（中階工程師更新知識），建議還是照順序讀，但可以加快前 8 天的節奏——環境安裝、開發工具這些你大概本來就會，重點放在骨架重構（Day 5）跟每天冒出來的「[NEW]」標記。
• 如果你是第二種（新手從零學），請務必照順序讀，不要跳。這系列的範例是累加式的——Post/User 這組資料模型從 Day 9 建立後，後面 20 天都在用同一組資料反覆延伸，跳著讀會遇到「這個 PostService 是哪裡來的」這種斷層。
• 如果你是第三種（評估升級的維運者），建議先看 VERSION_DIFF.md，抓出你的專案真正會受影響的條目，再回來看對應那天的細節說明，不需要通讀全部 30 天。

30 天大致會怎麼走

系列分成四個階段，新版才有的內容就近安插進對應主題：

1. 基礎建置（Day 2-8）：環境安裝、開發工具、新版 Starter Kit、全新的應用程式骨架（bootstrap/app.php）、Config、路由、常用 Helper。骨架這塊是這一季份量最重的地方之一。
2. Eloquent 與 MVC（Day 9-14）：Model、查詢建構器、View/Blade、Controller、RESTful API 設計，會把 Laravel 11 新增的屬性轉型 casts() 方法、Laravel 13 的 JSON:API 支援安插進對應章節。
3. 架構與內部機制（Day 15-25）：Logging、Middleware、Validation、Exception、Queue、多語系、請求生命週期、OOP/SOLID、Service Container/Provider、Session、排程與自訂指令——這段份量最扎實，也是 Kernel.php 消失後影響最大的一塊。
4. 實戰與生態圈（Day 26-30）：呼叫外部 API、測試、套件生態（Telescope/Sanctum/Octane/Socialite/Laravel Boost）、LINE Bot + OpenAI 實戰整合、版本控制與部署上線，最後用一天回顧整個系列並展望 Laravel 13 的新能力（Reverb 即時通訊、AI SDK、語意搜尋）。

![30 天路線圖：Day 1 系列介紹，接著依序是基礎建置（Day 2-8）、Eloquent 與 MVC（Day 9-14）、架構與內部機制（Day 15-25）、實戰與生態圈（Day 26-30）四個階段]

這四個階段不是隨便分的，背後有一個刻意的順序邏輯：先建立骨架的心智模型（階段一），再用它撐起資料層跟畫面層（階段二），接著把「一個請求進來到出去，中間會經過哪些關卡」的完整機制講透（階段三），最後才進到「這些機制怎麼組合成一個真正上線的產品」（階段四）。如果你發現自己在某一天卡住，通常代表前面某個階段的地基還沒打穩，回頭補那一天會比硬撐往下讀更有效率。

blog-app：貫穿 30 天的示範專案

這系列不會用零散的程式碼片段東拼西湊，而是從 Day 4 開始，一起建立並持續擴充一個叫做 blog-app 的部落格系統（Day 2、3 先把環境跟開發工具準備好）。先在這裡把它的樣貌交代清楚，讓你對接下來 30 天要蓋的東西有具體想像：

• 核心資料模型：Post（文章）與 User（作者），一對多關聯。Day 9 建立，Day 11 補上屬性轉型跟寫入操作，之後每一天幾乎都會用到。
• 對外介面：Day 12-13 先蓋傳統的 Blade 網頁介面，Day 14 再擴充出一套完整的 RESTful API（含 Laravel 13 的 JSON:API 支援），兩種介面共用同一組資料層。
• 背景機制：Day 19 加上文章發布通知的 Queue Job，Day 25 加上排程清除過期草稿的指令，這些都是「使用者不需要等待」的背景工作。
• 架構分層：Day 23 會把 Controller 裡直接操作 Eloquent 的寫法，重構成 Service + Repository 分層，這是這系列在「該不該提早引入抽象」這個爭議話題上明確表態的地方（DECISIONS.md 有完整的取捨紀錄）。
• 實戰整合：Day 29 幫 blog-app 加上一個串接 OpenAI 的 LINE 聊天機器人，並真正部署上線到 Render——這天你會發現前面 28 天教的東西，原來全部都在為這一天鋪路。

一路跟下來，Day 30 收尾時你手上會有一個雖然功能簡單、但架構完整、真正上線過的 Laravel 13 專案，而不是 30 段互相沒有關聯的程式碼片段。

Laravel 10 到 13，先看這張地圖

在進入細節之前，你需要先有一個總體印象：這三個大版本之間，哪些是「多數專案都會有感」的變動，哪些只是邊角案例。以下是這系列會反覆提到的重點，之後每一天遇到對應主題時，我會再展開講清楚，這裡先建立框架：

這張表刻意只列「這系列會實際用到、會影響 blog-app 寫法」的項目，不是完整的 changelog——每個大版本實際上都有幾十條變動，但多數是邊角案例（例如某個很少人用的 Contract 新增了一個方法簽名）。完整清單如果你有興趣，可以直接查官方的 Upgrade Guide（laravel.com/docs/13.x/upgrade），但老實說，逐條讀那份文件的體驗不會太好——它是寫給「已經在用某個版本、要升級到下一版」的人快速核對用的，不是寫給想理解「這些變動為什麼發生」的人看的。這系列存在的意義，某種程度上就是把那份清單重新組織成「有故事線的敘述」。

一個容易被誤解的地方：版本號不等於「破壞程度」

新手很容易有個直覺：版本號跳得越大（10→11），變動應該越大；小版本（12→13）變動應該越小。這個直覺在 Laravel 這裡不完全成立。Laravel 11 的骨架重構確實是近十年最大幅的一次改動，但 Laravel 12 表面上是「維護型」版本，實際上做的是哲學層級的轉向——官方認證方案從 Breeze/Jetstream 換成全新的 Starter Kit 系統，這件事對「你開新專案時該做的第一個決定」影響巨大，卻很容易被「這只是小版本」的印象輕忽。反過來，Laravel 13 雖然版本號又跳了一位，但骨架本身完全沒動，多數變動是「新增能力」（AI SDK、JSON:API）而不是「改變既有寫法」。

這系列採用的分類方式（後面 Day 30 會再深入展開）是把每個變動分成三個層次：語法平移（寫法變了但概念不變，兩種寫法通常能並存）、位置搬家（功能沒變但設定位置整個換了）、哲學轉向（官方推薦的做法本身換了方向）。用這個框架去理解版本差異，會比單純記「10→11 怎樣、11→12 怎樣」更容易在未來（14、15…）自己判斷一個新版本公告到底該不該緊張。

看到這裡你可能會緊張：「這麼多變動，我是不是要重學一次 Laravel？」不用擔心——Laravel 一貫的哲學是盡量不破壞既有寫法，官方甚至在文件裡明講「Laravel 11 雖然引進了新骨架，但完全不要求既有的 Laravel 10 專案跟著改結構」。這些變動絕大多數是「新專案的預設值變了」、「官方現在推薦的寫法變了」，而不是「你原本的程式碼會壞掉」。這系列的任務就是幫你把「新專案現在該長什麼樣子」跟「新寫法為什麼比較好」講清楚，讓你不管是帶著舊專案升級、還是開新專案，都能用對現在的最佳實踐。

常見疑慮先回答

Q：沒看過第一季，直接從這裡開始可以嗎？
可以，而且某種程度更輕鬆——你不用先學一套舊骨架、再學怎麼「轉換」過來，Day 5 開始直接就是 Laravel 13 現在的樣子。第一季的內容有興趣可以回頭翻，套件生態、開發工具那幾篇還是能建立不錯的概念，只是版本細節請以這一季為準。

Q：30 天塞得下嗎？
Helpers 跟查詢建構器這種「上百個方法逐條列」的參考手冊型內容，本來就不適合日更文章。這一季改用「精選常用方法＋速查表」的方式編排，最常用、最容易搞混的講深，其餘留連結自己查官方文件——這也比較貼近實際開發習慣，沒有人會把所有 Helper 背下來，重點是知道有哪些工具可以用。

Q：判斷取捨的過程看得到嗎？
看得到。哪些主題保留、哪些合併、哪些直接捨棄，只要是「沒有唯一正確答案」的決定，我都記在系列附帶的 DECISIONS.md 裡，包含當時考慮過哪些選項、為什麼選這個。好奇某個章節為什麼這樣安排，都可以回去查。

Q：這系列讀完，我就能直接上手一個正式的商用專案嗎？
老實說，不會百分之百。這系列教的是「Laravel 13 現在該怎麼寫」，涵蓋一個中小型專案需要的絕大多數概念——路由、資料層、驗證、佇列、測試、部署都會走一遍。但一個真正的商用專案還會牽涉到團隊協作規範、CI/CD 流程細節、正式環境的監控告警、資安稽核這些跟框架本身關係較小、更偏組織與流程的東西，這些不在 30 天的範疇內。你可以把這系列當作「打穩地基」，地基打穩之後，這些額外的東西是在實際專案裡邊做邊學會更有效率的部分。

Q：如果我在讀的當下 Laravel 已經出到 14 版了怎麼辦？
先別慌。看 Day 30 會講到的「三層次框架」（語法平移／位置搬家／哲學轉向），去讀官方的 release notes，通常十分鐘內就能判斷這個新版本對你影響多大。如果剛好遇到另一次像 Laravel 11 那樣的骨架級重構，那大概真的值得再等一部「S3」；但如果只是新增幾個 Helper 函式或某個 Facade 多了一個方法，這系列建立的知識骨架大概率還是站得住腳的——版本號會一直往前跳，但「理解一個框架為什麼這樣設計」這件事的保鮮期通常比你想的長。

小結

這一季不是換個版本號重貼一次，而是一次真正的知識更新：版本相關的每個地方都核對過官方文件重新校準，Laravel 11 到 13 之間值得學的新功能就近安插進對應主題。接下來 Day 2 到 Day 8 會先把環境建置好、把 blog-app 這個部落格系統從零建起來，之後 30 天的所有範例都會圍繞著這個專案的 Post（文章）與 User（作者）展開。

千里之行，始於足下 — 老子

明日預告

Day 2 從最基礎的地方開始：Laravel 13 需要的 PHP 版本、怎麼安裝、以及「多版本 PHP 並存」這個老技巧現在還適不適用。